1. Technical Field of the Invention
This invention pertains to security over virtual private network (VPN) connections. More particularly, it relates to gateway support for multiple overlapping remote networks.
2. Background Art
Virtual Private Networks (VPNs) are being increasingly deployed, over the existing Internet infrastructure, in support of B2B, supply chain logistics, and as a networking cost-reduction for an enterprise when communicating to its own branch offices. Typically, a business will organize its VPNs for a site or geographic area in a single VPN gateway. Each gateway will support many independent VPN connections from many remote systems, or remote gateways to smaller branch office networks, or suppliers (for example). The term “VPN connection” is another term referring to what is generally called an “IP Sec tunnel”, the latter being defined in RFC2401.
A problem occurs when remote networks have IP addresses which overlap with each other. For example, assume company A has a VPN gateway and wants to set up two VPN connections, one with a supplier and another with a west coast branch office (of company A). Assume both the supplier network and the branch office network have a system with IP address 1.2.3.4. The extent of IP address overlap can, in general, range from a single IP address to entire subnets of hundreds of IP addresses. For this example, assume further that both supplier and branch office addresses are routable inside the network of company A. There are two problem aspects caused by overlap like this. First, packets distinction: if two 1.2.3.4 packets from the different 1.2.3.4 systems are both going to the same server in A's network, how can the server tell them apart? Second, tunnel determination: what does VPN gateway A do with the response packet with destination IP address of 1.2.3.4? That is, should it go to the supplier subnet, via the VPN connection to the supplier's VPN gateway or should it go to the branch office subnet via the VPN connection to the branch office gateway?
In special cases like the above, the problem is fairly simple to solve—in this case, since the branch office is part of network A, the administrators at the VPN gateway of network A might just ask the branch office to change the IP address of the 1.2.3.4 machine (once the problem is detected). Another possible solution would be to use network address translation (NAT) in either the supplier or the branch office network, prior to the supplier or branch office VPN gateway (before the traffic entered the VPN connection, because NAT cannot be applied to IPsec based VPN traffic).
But these solutions are unworkable in the general case. Consider that gateway A may need to set up VPN connections with scores of remote gateways, some not even known beforehand. Further, with the widespread use of designated private subnets (e.g. 10.*.*.*), collision opportunities are enhanced.
Another scenario which leads to the same problems is of a company with multiple remote locations, all known beforehand, where the I/S and network people would like to make each remote site identical (same number of systems, same OS's, same network, same application, same addresses) to ease configuration and system management of the remote sites. A general, scalable and realistically manageable solution needs to occur at the gateway A end of these VPN connections where gateway A does not know beforehand the IP address of the remote Internet Key Exchange (IKE) server, and must be largely automatic, needs to handle any arbitrary overlapping remote IP address sets with differing amounts of overlap, n-way overlap, etc. And, of course, the solution should not have to depend on after-the-fact detection of overlap, but rather should be able to handle overlap as it occurs.
All VPN scenarios that face the remote address overlap problem can be classified into two sets; set s1) those scenarios in which the remote VPN connection endpoint (remote IKE server) address is known ahead of time, and set s2) those scenarios in which the remote VPN connection endpoint is not known. A solution to the sl class of scenarios is described in co-pending patent application Ser. No. 09/240,720 filed 29 Jan. 1999 by E. B. Boden, et al. for System and Method for Network Address Translation Integration With IP Security; Ser. No. 09/595,950 filed 16 Jun. 2000 by E. B. Boden, et al. for System and Method for Network Address Translation Integration With IP Security; and Ser. No. 09/578,215 filed 23 May 2000 by E. B. Boden, et al. for System and Method for Network Address Translation Integration With IP Security. The s2 class of scenarios is solved by the current invention.
What makes the S2 scenarios different is this; since the remote IKE endpoint is unknown, there are two direct implications: first, the connections must be initiated remotely (hence the gateway of the local network is in ‘responder mode’); and second, the gateway of the local network must have configured a VPN Policy with (logically) a destination IP address of ‘any’. Therein lies the problem; within a given VPN policy VPN connections cannot overlap, but here a single VPN policy is exactly what is needed. The essential relationship here is one VPN connection filter is dynamically loaded for each VPN policy that successfully negotiates IKE Phase 2 Security Associations (SAs).
What does filtering have to do with VPN? Normally with IPsec (the underlying protocols of VPN), an outbound packet is filtered (run through a series of IP packet filters) to determine which VPN connection it belongs in (should be encapsulated in), if any. (This is true for all vendors' VPN implementations.) This is the heart of the problem; if two filters for the same VPN connection overlap, then the one which occurs first will match packets ‘meant’ for a later overlapping filter because early filters mask out traffic from later overlapping filters (in general). So, filter order matters . . . but what is the right order? and how can the order be changed on a per packet basis?
This problem may exist for other TCP/IP tunneling scenarios, in addition to IPsec-based VPN's; for example, IPv6's 6to4 and 6over4, UDP tunneling (IPv4) through NAT, and others.
It is an object of the invention to provide an improved system and method for operating a local gateway in support of multiple overlapping remote networks.
It is an object of the invention to provide a system and method for a local network which allows communication with a plurality of overlapping remote networks.
It is an object of the invention to provide a system and method for overriding connection filters in order to support multiple overlapping remote networks.
It is an object of the invention to provide a system and method operating a local gateway in support of communications with multiple overlapping remote networks which requires no changes to those remote networks or the gateways to those remote networks.
It is an object of the invention to provide a system and method whereby multiple remote sites, even with overlapping addresses, may be configured using source-in NAT such that the traffic inside a local gateway is non-conflicting.